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Status of This Memo 
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Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
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Abstract 


This specification provides a mechanism for Lightweight Directory 
Access Protocol (LDAP) clients to obtain the authorization identity 
the server has associated with the user or application entity. This 
mechanism is specified as an LDAP extended operation called the LDAP 
"Who am I?" operation. 


1. Background and Intent of Use 


This specification describes a Lightweight Directory Access Protocol 
(LDAP) [RFC4510] operation that clients can use to obtain the primary 
authorization identity, in its primary form, that the server has 
associated with the user or application entity. The operation is 
called the "Who am I?" operation. 


This specification is intended to replace the existing Authorization 
Identity Controls [RFC3829] mechanism, which uses Bind request and 
response controls to request and return the authorization identity. 
Bind controls are not protected by security layers established by the 
Bind operation that includes them. While it is possible to establish 
security layers using StartTLS [RFC4511] [RFC4513] prior to the Bind 
operation, it is often desirable to use security layers established 
by the Bind operation. An extended operation sent after a Bind 
operation is protected by the security layers established by the Bind 
operation. 
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There are other cases where it is desirable to request the 
authorization identity that the server associated with the client 
separately from the Bind operation. For example, the "Who am I?" 
operation can be augmented with a Proxied Authorization Control 
[RFC4370] to determine the authorization identity that the server 
associates with the identity asserted in the Proxied Authorization 
Control. The "Who am I?" operation can also be used prior to the 
Bind operation. 


Servers often associate multiple authorization identities with the 
client, and each authorization identity may be represented by 
multiple authzId [RFC4513] strings. This operation requests and 
returns the authzId that the server considers primary. In the 
specification, the term "the authorization identity" and "the 
authzId" are generally to be read as "the primary authorization 
identity" and the "the primary authzId", respectively. 


1.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14 [RFC2119]. 


2. The "Who am I?" Operation 


The "Who am I?" operation is defined as an LDAP Extended Operation 
[RFC4511] identified by the whoamiOID Object Identifier (OID). This 
section details the syntax of the operation’s whoami request and 
response messages. 


whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3" 
2.1. The whoami Request 


The whoami request is an ExtendedRequest with a requestName field 
containing the whoamiOID OID and an absent requestValue field. For 
example, a whoami request could be encoded as the sequence of octets 
(in hex): 


30 le 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31 
2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33 
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2.2. The whoami Response 


The whoami response is an ExtendedResponse where the responseName 
field is absent and the response field, if present, is empty or an 
authzId [RFC4513]. For example, a whoami response returning the 
authzId "u:xxyyz@EXAMPLE.NET" (in response to the example request) 
would be encoded as the sequence of octets (in hex): 


30 21 02 01 02 78 1c Oa 01 00 04 00 04 00 8b 13 
75 3a 78 78 79 79 7a 40 45 58 41 4d 50 4c 45 2e 
4e 45 54 


3. Operational Semantics 


The "Who am I?" operation provides a mechanism, a whoami Request, for 
the client to request that the server return the authorization 


identity it currently associates with the client. It also provides a 
mechanism, a whoami Response, for the server to respond to that 
request. 


Servers indicate their support for this extended operation by 
providing a whoamiOID object identifier as a value of the 
‘supportedExtension’ attribute type in their root DSE. The server 
SHOULD advertise this extension only when the client is willing and 
able to perform this operation. 


If the server is willing and able to provide the authorization 
identity it associates with the client, the server SHALL return a 
whoami Response with a success resultCode. If the server is treating 
the client as an anonymous entity, the response field is present but 
empty. Otherwise, the server provides the authzId [RFC4513] 
representing the authorization identity it currently associates with 
the client in the response field. 


If the server is unwilling or unable to provide the authorization 
identity it associates with the client, the server SHALL return a 
whoami Response with an appropriate non-success resultCode (such as 
operationsError, protocolError, confidentialityRequired, 
insufficientAccessRights, busy, unavailable, unwillingToPerform, or 
other) and an absent response field. 


As described in [RFC4511] and [RFC4513], an LDAP session has an 
"anonymous" association until the client has been successfully 
authenticated using the Bind operation. Clients MUST NOT invoke the 
"Who am I?" operation while any Bind operation is in progress, 
including between two Bind requests made as part of a multi-stage 
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Bind operation. Where a whoami Request is received in violation of 
this absolute prohibition, the server should return a whoami Response 
with an operationsError resultCode. 


4. Extending the "Who am I?" Operation with Controls 


Future specifications may extend the "Who am I?" operation using the 
control mechanism [RFC4511]. When extended by controls, the "Who am 
I?" operation requests and returns the authorization identity the 
server associates with the client in a particular context indicated 
by the controls. 


4.1. Proxied Authorization Control 


The Proxied Authorization Control [RFC4370] is used by clients to 
request that the operation it is attached to operate under the 
authorization of an assumed identity. The client provides the 
identity to assume in the Proxied Authorization request control. If 
the client is authorized to assume the requested identity, the server 
executes the operation as if the requested identity had issued the 
operation. 


As servers often map the asserted authzId to another identity 
[RFC4513], it is desirable to request that the server provide the 
authzId it associates with the assumed identity. 


When a Proxied Authorization Control is be attached to the "Who am 


I?" operation, the operation requests the return of the authzId the 
server associates with the identity asserted in the Proxied 
Authorization Control. The authorizationDenied (123) result code is 


used to indicate that the server does not allow the client to assume 
the asserted identity. 


5. Security Considerations 


Identities associated with users may be sensitive information. When 
they are, security layers [RFC4511] [RFC4513] should be established to 
protect this information. This mechanism is specifically designed to 
allow security layers established by a Bind operation to protect the 
integrity and/or confidentiality of the authorization identity. 


Servers may place access control or other restrictions upon the use 
of this operation. As stated in Section 3, the server SHOULD 
advertise this extension when it is willing and able to perform the 
operation. 


As with any other extended operations, general LDAP security 
considerations [RFC4510] apply. 
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6. 


8. 


8. 


IANA Considerations 
The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who am 
I?" extended operation. This OID was assigned [ASSIGN] by the 
OpenLDAP Foundation, under its IANA-assigned private enterprise 
allocation [PRIVATE], for use in this specification. 
Registration of this protocol mechanism [RFC4520] has been completed 
by the IANA. 
Subject: Request for LDAP Protocol Mechanism Registration 
Object Identifier: 1.3.6.1.4.1.4203.1.11.3 
Description: Who am I? 
Person & email address to contact for further information: 
Kurt Zeilenga <kurt@openldap.org> 
Usage: Extended Operation 
Specification: RFC 4532 
Author/Change Controller: IESG 
Comments: none 
Acknowledgement 
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"Authentication Response Control" [RFC3829] by Rob Weltman, Mark 
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The LDAP "Who am I?" operation takes it’s name from the UNIX 
whoami(1) command. The whoami (1) command displays the effective user 
ID. 
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contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
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Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
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